Proposed by Rustem Khubbatov (profile, biography) Don't forget to submit this proposal to official Google Melange site too!
How will I do that project
*************************************
I want to use my current term work as basis for the GSoC project. This is described below in the "Suggested timeline and milestones" section. I plan to add important features to the system, generalize it. I'll pay a lot of attention to the quality of source code, testing and documenting it to make useful and usable for other smalltalkers. I understand I'll have to apply to very serious problems (like communications, UI, web-programming) and I'll try my best to solve them.
What methodologies will I use
*************************************
I must admit I have little experience with modern software development methodologies. So, I relay on mentor's suggestions here.
Our approach is to use iterative programming with particular agile practices. Iterations are presented in the plan below. On each iteration start we will have a short planning session with a top-level (architecture) design. I'll try to avoid detailed up-front design in favor of "design in code" approach and concretely TDD when able to.
Suggested timeline and milestones
************************************
0. A greatly simplified prototype of the system is now being developed as my term project and it should be completed by the start of GSoC project providing the following:
- Pharo image with models of several devices and along with API to simulate changes in their properties
- Amber client able to display these devices with labels and SVG images
- Basic facilities for communication between Pharo and Amber (using WebSocket)
- Objects in Amber can ask for the values of device parameters (in order to display them)
- Pharo model objects can notify Amber subscribers about events
- Amber objects will probably be able to initiate actions in the Pharo image; the actions will result in changes of device parameters and cause event notfications sent to Amber
- Some ideas and concepts that will help to develop a communication protocol between client and server
I'm going to fulfill the following tasks within GSoC project:
1. Client presents structural changes on the server (for example, a device addition)
In Pharo, a script that adds a new device in the system is running; this results in displaying the new device in the client.
Duration: 3 days
2. Client displays and allows to modify device properties
A user may list device properties, see their values, change those values as well as add/remove properties.
Duration: 7 days
Total duration: 10 days
3. One-step actions (example: adding a device from client-side)
A user initiates a device-creation action, fills its description using client UI; the device is created on server, then client displays it in a list of devices.
Duration: 5 days
Total Duration: 15 days
4. Multiple-step actions (example: network discovery)
Network discovery involves several steps:
- The user initiates the action
- Client asks server for default parameters and provide them to user for modifications and sends back to server (it will use them during further steps)
- Server provides client with a list of seed routers that can be used to obtain available sub-networks; user reviews the list, edit it and confirms making client to send it back to server
- Server uses these routers to obtain subnets available for discovery and sends this information as network ranges to client for editing and then get them back to continue
- Address ranges specified by user are converted to a list of IP-addresses and the list is passed to client, again, for editing
- Final version of IP-address list is used for discovering working service in network; results are transmitted to user again to get a list of services to be added to system … etc.
Thus, actions are actually a sequence of data-exchange steps separated by user interactions. Continuations may be useful here.
Duration: 10 days
Total Duration: 25 days
5. There is a variety of ways to represent device properties
Different types of devices can be displayed as different images; device status can be represented with a color of that image or some additional elements on the image; numerical characteristics can be presented with text, gauges, graphs; …and so on. I'll implement several presentation tools and will try to present a unified engine considering the fact that the same device property may have different types presentation in different parts of system.
Duration: 5 days
Total Duration: 30 days
6. There should be a unified protocol for comunication between the client and server.
The protocol will be formed during the execution of previous tasks. At this stage it is possible to generalize it, refactor and refine source code, etc.
Duration: 15 days
Total Duration: 45 days
7. Making communication between client and server parallel
This is very important and one of the most complicated parts of the system.
Duration: 10 days
Total Duration: 55 days
8. UI-building facilities
This is actually the central part of the whole project.
I think of this task in terms of widgets — reusable components of UI. Here goes just some ideas about this task, I'll figure out a concrete schedule a bit later (when I'll be closer to the finish of my term project, but before the project starts anyway).
Widget…
- is a rectangular panel
- may have sub-components (which are also the "widgets")
- has a layout (a general algorithm for arranging components on the panel)
- knows all parameters need to place subcomponent
In this project i will only create widgets programmatically. Visual UI Builder is put aside (as, obviously, I do not have enough time to implement it)
As reusable object, widgets can be "bound" to different objects in system. For example, a widget created for a device can be used to present another device (of same or even another type); a single widget can be used as a subcomponent in different other widgets, etc.
Widget is simply an object. All of its "bindings" are just ivars and initialization is performed by conventional Smalltalk messages.
Widget can subscribe to events generated by other objects (both local and remote ones; stubs probably should be used here)
Duration: I plan to dedicate all the remaining time (except the final step presented below) to this task.
10. Testing and documenting
Duration: 20 days
Where I see the risk
***************************
Underestimation is very possible. In this case, the rescheduling will be done (by reviewing remaining tasks, selecting the most important ones, simplifying too complex problems and so on). More generally, my lack of experience may have a negative impact. I relay upon mentors' help here.
Technical difficulties with Pharo and Amber I intend to overcome with help from mentors and community.
The most difficult parts are communications and UI-building facilities. I'll give a special consideration to this aspects.
|